1. The Field of the Invention
The present invention relates to domain name resolution. More particularly, the present invention relates to systems, computer program products, and methods for resolving domain names based on client authentication.
2. The Relevant Technology
Security is a growing concern for many organizations (including families and individuals) that offer outside connections to computers on their home or business network. At any given time, an organization may provide access to certain computers over various networks (such as a local or wide area network, the Internet, etc.). For example, the organization may have an externally accessible computer to manage email, web content, financial or marketing data, technical information, or other content. While these external connections provide the organization with some benefits, they also introduce security concerns.
When an organization opens up a network computer to external access, the organization risks the possibility that unwanted persons (e.g., hackers) will gain access to restricted portions of that computer. Thus, organizations strike a balance between the need to allow remote access to potentially sensitive information and the chance a hacker may break through the security. To mitigate these risks, organizations often employ a firewall and other expensive security measures to restrict external access to their computers.
For example, an organization may implement any of one or more higher level secure communication protocols, such as Secure Sockets Layer (SSL) and Transport Layer Security (TLS) for encrypting data that passes between computers. The organization also may (or alternatively) employ a virtual private network (VPN) that provides access to an organization's network in part by forbidding entry of data packets that are not encrypted properly. An organization may enhance security further through lower level communication protocols, such as Internet Protocol Security (IPsec).
Many communication protocols, including those identified above, may transmit data intended for a private network over a public (or wide area) network through a “tunneling” protocol. Tunneling masks the transmission of private data sent over a public network so that certain information is inaccessible to the public network. Accordingly, an organization may implement one or more of these protocols to secure access to their computers.
Network connectivity allows for access to files and for conducting a variety of transactions from remote locations. Those wanting to access an organization's computer typically do so using a relatively easily remembered domain name that corresponds to one or more Internet Protocol (IP) addresses (or, in some cases one or more arbitrary text strings). IP addresses are numbers ranging from 32-bits (older standard: e.g., written as a set of four 8-bit numbers separated by periods) to 128-bits (more recent standard: e.g., written as a set of sixteen 8-bit numbers). IP addresses ordinarily represent an address for a computer on a network.
IP addresses, however, tend to be difficult to remember, and may change, especially within a particular network, depending on how a network server configures addresses (e.g., allowing static addresses, or requiring dynamic address assignment). Thus, a computer's domain name (e.g., www.company.com) often is a more convenient way to reference a particular computer on a network. Domain names are also convenient since domain names can be reassigned to different, or even multiple IP addresses, and hence may remain constant in spite of fairly significant changes in network configuration.
A domain name generally comprises a top-level domain (TLD), a second-level domain, and a server, protocol, and/or sub-domain. With reference to FIG. 1, “ns.company.com” 136 comprises three parts: “.com” represents the top-level domain 130, “company” represents a second-level domain with the “.com” TLD, and “ns” represents a server within the “company” second-level domain. The domain name, “ns.company.com” typically maps to, and can be thought of as, a readable version of an IP address. Frequently, the prefix letters “www” comprise a third level domain that represents a specific server for handling HyperText Transfer Protocol (HTTP) requests. Examples of sub-domains include prefixes preceding the second-level domain, such as in “private.company.com” 138 (or mail.company.com). In either case, a domain name server resolves domain names into domain name address for requesting clients.
Domain name servers (DNS servers, or name servers) are servers scattered over various worldwide zones, which can perform “name to address” translation—converting textual domain names into IP addresses and vice versa. To resolve a domain name, domain name servers refer to a distributed database of domain names and respective IP addresses. Requests for domain name resolution often are referred to as DNS queries. As described in more detail below, a domain name server may reference a cache containing recently accessed domain names with their corresponding IP addresses or may request the information from another domain name server.
The server responsible for maintaining domain name resolution information for a particular domain or sub-domain is known as an authoritative name server for the domain or sub-domain. Accordingly, a domain name server may function as an authoritative name server, a domain name cache server, or some combination of both. Except for relatively small domains or sub-domains, a single domain name server typically does not contain a complete reference of all domain names and corresponding IP addresses. Rather domain name servers usually are organized to coordinate and distribute available domain name information due to both performance and size considerations. The domain name server organization for the Internet follows a hierarchy beginning with several distributed root name servers, e.g., 100, 110, 115, etc., followed by various top-level domain name servers, e.g., “.org” 125, “.com” 130, “.edu” 150, “.net” 180, etc., and various more localized domain names servers, e.g., 134, 136, 132, 152, 154, etc.
An authoritative name server, such as name server 136, maintains domain name resolution information (domain names and corresponding IP addresses) for a portion of the hierarchy. For example, the authoritative name server “ns.company.com” 136 may be authoritative for various sub-domains in the “company” organization, such as, “private.company.com” 138, product.company.com (not shown), accounting.company.com (not shown), and mail.company.com (not shown). Similarly, other domain name servers in the “.com” or other hierarchies may be authoritative for a certain geographic area, such as Seattle, or for a particular range of IP addresses, such as the range of IP addresses assigned by an Internet Service Provider or registrar of domain names. Regardless, if a particular name server cannot determine the appropriate IP address for a given domain name, such as “private.company.com” 138, the name server may relay or forward the domain name request to other domain name servers, and eventually to the authoritative name server “ns.company.com” 136, if the information is not cached at intervening name servers.
By way of illustration, Client B requests 140 access to “http://humanities.school.edu” which requires the domain name “humanities.school.edu” to be resolved. The server “physics.school.edu” 156 caches some domain name resolution information, but in this example does not have the IP address for the “humanities.school.edu” domain name and therefore queries server 154. Name server “ns.school.edu” 154 is an authoritative name server for the “school.edu” domain and provides an authoritative response 145, indicating that “192.168.2.2” is the IP address for the “humanities.school.edu” domain name. This response may be forwarded 147 to client B. (It should be noted that throughout this document, an effort is made to use fictitious IP addresses which are reserved for local use.) Because name server “ns.school.edu” 154 is authoritative for the “school.edu” domain, “ns.school.edu” would not forward this request on to other DNS servers, but rather would respond that “humanities.school.edu” was unknown if no IP address were available. Upon receiving a response from “ns.school.edu” 154, server 156 “physics.school.edu” ordinarily caches the domain name and corresponding IP address for some period of time.
Request 160 from Client A for content at “http://www.foxnews.com” illustrates an example of cached domain name resolution information. In this case, server 156 previously has received domain name resolution information for “www.foxnews.com” and therefore can respond 165 with an IP address “10.5.5.5” and does not need to query other DNS servers. For frequently requested domain names, it is likely that a DNS server within the hierarch will have cached the domain name resolution information and it will not be necessary to access an authoritative server. It is possible to bypass any DNS caching, and query only the authoritative name server for the domain name resolution information, but due to performance considerations, bypassing the caching information is relatively uncommon.
FIG. 2 shows how the process follows a slightly different path when a client requests a domain name that no name server in its hierarchy recognizes. For example, a client in the “school.edu” domain makes a request 260 for a domain name in the “company.com” domain. In this particular case, the request 260 is for resolution of the domain name “private.company.com” 238. For a variety of reasons, it is possible that none of the intermediary name servers 256, 254, 252, and 250 will recognize the requested domain name 260 from their cache.
Note that in FIG. 2, the example hierarchy does not show communication between the “.edu” DNS servers and the “.com” DNS servers. In practice, there is nothing to prevent one DNS server from communicating with another DNS server, provided the one server knows about the other. Accordingly, server 254 may be configured to query DNS server 234 for “.com” domain names, and so on. The particular hierarchy shown in FIG. 2, therefore, is only one example hierarchy that provides helpful context for describing the present invention, which is not restricted to any particular organization of DNS hierarchies.
For request 260, it is also possible that none of these intermediate name servers will recognize the authoritative name server 236 in their databases. In this case, the appropriate top-level name server “.edu” 250 or root name server 210 refers the request to a name server, e.g, 234, in the “.com” 230 hierarchy based on the top-level portion of the domain name “private.company.com” request. Alternatively, the top-level name server “.com” 250, root name server 210, or any other intermediate name server, may simply recognize that the name server “ns.company.com” 236 is authoritative for the “company.com” domain, and relay the request to the appropriate authoritative name server 236.
Typically, authoritative name servers, do not base their domain name resolution response on the client requesting the IP address. In some circumstances, communication between DNS servers may have a security component, but secure communication of DNS information is not ordinarily based on the requesting client. As a result, “ns.company.com” 236 is not able to shield the IP address of “private.company.com” from some clients, but make it available to others.
Nevertheless, for security reasons, an organization may not want DNS information available for certain servers. For example, “private.company.com” may operate as a gateway to a “company.com” private network or may be an internal server for “company.com” that may give hints to network topology, reveal project names, or otherwise disclose potentially sensitive information. If “ns.company.com” responds 265, the IP address “10.1.1.1” may be cached at various intermediate DNS servers, such as “physics.school.edu” 256, and become more widely known and accessible because “physics.school.edu” 256 and/or other intermediate domain name servers can then respond 267 with the IP address corresponding to “private.company.com” for requests from other clients. To guard against this security risk, many organizations prohibit domain name resolution for a server such as “private.company.com” and allow access only from within a private network or if a client knows the correct IP address.
As described above, however, IP addresses are difficult to remember and subject to change. Accordingly, prohibiting domain name resolution as a security measure represents a significant burden for clients. What is needed, therefore, is a way of allowing only authorized clients to resolve certain domain names and receive the corresponding IP address, so that clients can resolve and access only those domain names for which the clients are authorized.